-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ajout du champ notification_email
pour les usagers, modifiable uniquement via l'api
#5003
Conversation
…ultiple user with same email
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
J'ai fait un premier tour, je suis trop sous l'eau cette semaine car on est en sous-effectif, je reste bien chaud pour discuter des points soulevés, on peut s'appeler demain ou vendredi !
notification_email
pour les usagers, modifiable uniquement via l'api (par rdv-insertion)notification_email
pour les usagers, modifiable uniquement via l'api
- if user.notification_email.present? | ||
li= object_attribute_tag(user, :notification_email, clickable_user_notification_email(user)) | ||
.text-muted.mb-2 | ||
| Cette valeur n'est pas modifiable et a été renseignée par un partenaire tiers (ex : rdv-insertion...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Je reviendrais plus tard pour mettre une explication plus détaillée, mais je pense qu'on peut se passer de cette info supplémentaire, et toujours afficher le preferred_email
ligne 9.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suite à notre discussion de ce matin j'ai fait un commit qui permet de modifier dynamiquement le champ email ou notification_email de l'usager à l'edit. L'agent n'est ainsi pas perturbé, n'a pas connaissance de la distinction email (devise) et notification_email. On a plus besoin de cette phrase.
4edfdb5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ça fait un peu peur mais c'est une bonne première étape avec la dé-corrélation des comptes et des profils ! 👌
Pour moi c'est OK de déployer ça. 🚀
A la suite de cette PR, nous envisageons une migration (copie de
notification_email
et mettre
Si j'ai bien compris, ça signifie que vos usagers ne pourront plus se créer un compte pour accéder à leur RDVs, c'est ça ?
…agouv/rdv-service-public into add_notification_email_field_on_user
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉 Trop bien ! Merci pour le travail fait sur ce sujet, ça va être très utile pour la création d'usager dans le cadre des intégrations.
Comme on en a discuté, on peut merger ça, mais il faut réparer la recherche avant de s'en servir (en faisant attention à migrer les indexes de recherche de manière safe pour éviter de se retrouver dans un état où on n'a pas d'index et on casse l'application).
Ensuite il faudra assez vite permettre l'invitation d'un usager qui a juste un notification_email (probablement un ajustement à faire dans un controller devise, avec peut-être la possibilité de choisir une adresse mail différente de celle des notifications).
On pourra ensuite faire une migration de l'ensemble de la base.
Après ça, à plus long terme on pourra même imaginer du dédoublonnage de compte usager dans l'interface pour les usagers
42a2fdf
to
7310da9
Compare
7310da9
to
1021793
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 🙌 💯 !
Closes gip-inclusion/rdv-insertion#2065
Contexte
Nous avons besoin de pouvoir assigner à différents usagers le même email de notification lors de la création des comptes pour les invitations à prendre rdv dans rdv-insertion dans le cas d'un couple conjoint demandeur RSA ou dans le cas d'un déménagement (plusieurs comptes seront créés sur les différents territoires).
Un début d'implémentation avait été réalisé en septembre dernier ici et ici. Il n'a pas été poursuivi car cela avait des répercussions trop importantes, notamment le renommage du champ
email
enaccount_email
.Suite à cela une spec fonctionnelle et technique a été réalisée pour évaluer les options possibles.
Une discovery a été mené par @NesserineZarouri à ce sujet pour identifier les besoins coté RDVSP.
Il en est ressorti qu'il n'y a pas de besoin de cette fonctionnalité aujourd'hui coté RDVSP.
On a donc décidé de choisir l'implémentation minimale de la fonctionnalité tout en pouvant évoluer plus largement au besoin.
Solution
On ajoute le champ
notification_email
pour les usagers.Ce champ est modifiable uniquement via l'api.
Dans le front on affiche l'email de notification dans la show de l'usager si celui ci existe pour que les agents rdvi connectés à rdvsp puissent avoir l'information. On affiche également un avertissement pour expliquer que le champ n'est pas modifiable et a été renseigné par un partenaire externe.
Dans l'edit du formulaire de l'usager on affiche le champ email sauf si notification_email existe.
La traduction i18n des différents champs email/notification_email et preferred_email (l'un ou l'autre) est la même pour ne pas perturber l'agent avec ces notions.
Si un email est renseigné celui ci prendra la valeur du champ
email
et un callback effacera le champnotification_email
de l'usager, les 2 ne pouvant pas être rempli simultanément.Les mailers sont modifiés pour utiliser
email
ounotification_email
en fonction de celui qui est rempli.Techniquement et prochaines étapes
Coté rdv-insertion pour des mises à jour d'usagers existants nous allons modifier notre code ici pour interroger le show de l'api de rdvsp (celui ci renverra les valeurs des champs
email
etnotification_email
). Une fois qu'on a l'information on appellera l'update avecemail
ounotification_email
en fonction.Les nouveaux usagers seront toujours créés avec le notification_email :
A la suite de cette PR, nous envisageons une migration (copie de
email
dansnotification_email
et mettreemail
à nil) pour les usagers rdv-insertion qui sont uniquement dans des organisations rdv-insertion et qui ne se sont jamais connectés à l'application. Cela permettra d'avoir un état des enregistrements usagers cohérent avec le nouveau mode de fonctionnement.Quelques chiffres sur les usagers concernés :
5716 usagers sur des verticales rdv-insertion uniquement avec un compte devise rdvsp activé. (Pas de migration)
242 940 usagers sur des verticales rdv-insertion uniquement et qui n'ont pas activé leur compte (à migrer de
email
versnotification_email
). Cela représente 1/4 de l'ensemble des usagers de rdvsp.700 usagers rdv-insertion avec un compte rdvsp activé sur plusieurs verticales. (Pas de migration)
14 928 usagers rdv-insertion avec un compte rdvsp non activé sur d'autres verticales. (Pas de migration)